Configuring Proxy Sets

The Proxy Sets table lets you configure up to 5,000 Proxy Sets. A Proxy Set defines the address (IP address or FQDN) and transport type (e.g., UDP or TCP) of a SIP server (e.g., SIP proxy and SIP registrar server). The Proxy Set represents the destination of the IP Group configuration entity.

●

The maximum number of addresses that you can configure in the Proxy Address table ("child" of the Proxy Sets table) per Proxy Set is 50 . The address can be an IP address in dotted-decimal notation or a DNS hostname (FQDN).

●

The maximum number of supported DNS-resolved IP addresses per Proxy Set is 50.

●

The maximum number of supported DNS-resolved IP addresses for all Proxy Sets combined is 20,000. If the DNS resolution provides more than this number, it ignores the extra addresses.

●

An SRV query sent by the device can return up to 50 hostnames. For each hostname, the subsequent DNS A-record query sent by the device can resolve into up to 50 IP addresses.

Multiple proxy servers enables you to implement proxy load balancing and redundancy. These features are supported by the device's proxy keep-alive feature, which when enabled, sends keep-alive messages (SIP OPTIONS) to all configured proxy servers to determine their connectivity status (offline or online). You can also configure the device to consider the proxy as offline if specific SIP response codes are received in response to the keep-alive messages. You can configure the number of required consecutive successful keep-alive messages before the device considers a previously offline proxy as online. This mechanism avoids the scenario in which the device falsely detects a proxy as being online when it is actually offline, resulting in call routing failure.

You can assign each Proxy Set a specific TLS Context (TLS configuration), enabling you to use different TLS settings (including certificates) per SIP entity (IP Group).

You can also enable the device to classify incoming SBC SIP dialogs to IP Groups, based on Proxy Set. If the source address of the incoming SIP dialog is the same as the address of a Proxy Set, the device classifies the SIP dialog as belonging to the IP Group that is associated with the Proxy Set.

To use a configured Proxy Set, you need to assign it to an IP Group in the IP Groups table (see Configuring IP Groups). When the device sends INVITE messages to an IP Group, it sends it to the address configured for the Proxy Set. You can assign the same Proxy Set to multiple IP Groups (belonging to the same SRD).

●

It is recommended to classify incoming SIP dialogs to IP Groups based on Classification rules (see Configuring Classification Rules) instead of based on Proxy Sets.

●

To view connectivity status of Proxy Sets, see Viewing Proxy Set Status.

The Proxy Set is configured using two tables with parent-child relationship:

■

Proxy Sets table (parent): Defines the attributes of the Proxy Set such as associated SIP Interface and redundancy features - ini file parameter [ProxySet] or CLI command, configure voip > proxy-set

■

Proxy Set Address table (child): Defines the addresses of the Proxy Set - table ini file parameter [ProxyIP] or CLI command, configure voip > proxy-ip > proxy-set-id

➢

To configure a Proxy Set:

Open the Proxy Sets table (Setup menu > Signaling & Media tab > Core Entities folder >Proxy Sets).

Click New; the following dialog box appears (screenshot has been cropped due to page size):

From the 'SRD' drop-down list, select an SRD.

Configure a Proxy Set according to the parameters described in the table below.

Click Apply.

Configure proxy addresses for the Proxy Set:

Select the index row of the Proxy Set that you added, and then click the Proxy Address link located below the table; the Proxy Address table opens.

Click New; the following dialog box appears:

Configure the address of the Proxy Set according to the parameters described in the table below.

Click Apply.

Proxy Sets Table and Proxy Address Table Parameter Description

Parameter

Description

'SRD'

voip-network proxy-set > srd-id

[SRDName]

Assigns an SRD to the Proxy Set.

Note:

■

The parameter is mandatory and must be configured first before you can configure the other parameters in the table.

■

To configure SRDs, see Configuring SRDs.

General

'Index'

configure voip > voip-network proxy-set

[Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

proxy-name

[ProxyName]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters.

Note:

■

Configure each row with a unique name.

■

The parameter value can't contain a forward slash (/).

■

The parameter value can't be configured with the character string "any" (upper or lower case).

'SBC IPv4 SIP Interface'

sbcipv4-sip-int-name

[SBCIPv4SIPInterfaceName]

Assigns an IPv4-based SIP Interface for SBC calls to the Proxy Set.

Note:

■

The parameter appears only if you have configured an IPv4 network interface in the IP Interfaces table (see Configuring IP Network Interfaces).

■

At least one SIP Interface must be assigned to the Proxy Set.

■

All SIP Interfaces assigned to the Proxy Set must be either IPv4 addresses or IPv6 addresses (not both).

■

To configure SIP Interfaces, see Configuring SIP Interfaces.

'SBC IPv6 SIP Interface'

sbcipv6-sip-int-name

[SBCIPv6SIPInterfaceName]

Assigns an IPv6-based SIP Interface for SBC calls to the Proxy Set.

Note:

■

The parameter appears only if you have configured an IPv6 network interface in the IP Interfaces table.

■

At least one SIP Interface must be assigned to the Proxy Set.

■

All SIP Interfaces assigned to the Proxy Set must be either IPv4 addresses or IPv6 addresses (not both).

'TLS Context Name'

tls-context-name

[TLSContextName]

Assigns a TLS Context (TLS configuration) to the Proxy Set.

By default, no TLS Context is assigned. If you assign a TLS Context, the TLS Context is used as follows:

■

Incoming calls: If the 'Transport Type' parameter (in this table) is set to TLS and the incoming call is successfully classified to an IP Group based on the Proxy Set, this TLS Context is used. If the 'Transport Type' parameter is set to UDP or classification to this Proxy Set fails, the TLS Context is not used. Instead, the device uses the TLS Context configured for the SIP Interface (see Configuring SIP Interfaces) used for the call; otherwise, the default TLS Context (ID 0) is used.

■

Outgoing calls: If the 'Transport Type' parameter is set to TLS and the outgoing call is sent to an IP Group that is associated with this Proxy Set, this TLS Context is used. Instead, the device uses the TLS Context configured for the SIP Interface used for the call; otherwise, the default TLS Context (ID 0) is used. If the 'Transport Type' parameter is set to UDP, the device uses UDP to communicate with the proxy and no TLS Context is used.

To configure TLS Contexts, see Configuring TLS Certificates.

Keep Alive

'Proxy Keep-Alive'

proxy-enable-keep-alive

[EnableProxyKeepAlive]

Enables the device's Proxy Keep-Alive feature, which checks connectivity with all the proxy servers of the Proxy Set, by sending keep-alive messages.

■

[0] Disable (default).

■

[1] Using OPTIONS = Enables the Proxy Keep-Alive feature using SIP OPTIONS messages. The device sends an OPTIONS message every user-defined interval, configured by the 'Proxy Keep-Alive Time' parameter (in this table). If the device receives a SIP response code that is configured in the 'Keep-Alive Failure Responses' parameter (in this table), the device considers the proxy as offline. You can also configure if the device uses its IP address, the proxy's IP address, or the device's name in the OPTIONS message, using the [UseGatewayNameForOptions] parameter.

■

[2] Using REGISTER = Enables the Proxy Keep-Alive feature using SIP REGISTER messages. The device sends a REGISTER message every user-defined interval, configured by the [SBCProxyRegistrationTime] parameter. Any SIP response from the proxy - success (200 OK) or failure (4xx response) - is considered as if the proxy is online. If the proxy doesn't respond to INVITE messages sent by the device, the proxy is considered as offline. The device sends keep-alive REGISTER messages only to one proxy. Only if the proxy fails to respond to the keep-alive, does the device send the keep-alive REGISTER message to the next proxy.

■

[3] Using OPTIONS on Active Server = Enables the Proxy Keep-Alive feature using SIP OPTIONS messages (similar to the Using OPTIONS value), except that the proxy servers to which the keep-alive messages are sent depend on the settings of the Proxy Set's 'Redundancy Mode' parameter (see below):

✔

Parking: The device sends keep-alive OPTIONS messages only to the currently active proxy server (to which it is connected and using).

✔

Homing: The device sends keep-alive OPTIONS messages to the currently active proxy server and to all proxy servers with higher priority (according to the 'Proxy Priority' parameter in this table) than the active server. Once a higher priority server goes online, the device stops sending the keep-alive OPTIONS messages to the previously active server and connects to the higher priority server. The device now sends keep-alive messages to this newly active server and all other servers with higher priority.

✔

If the 'Redundancy Mode' parameter is not configured (empty) and the Proxy Set's 'Proxy Load Balancing Method' parameter (in this table) is configured to any value other than Disable, the device sends the keep-alive OPTIONS messages to all proxy servers (same behavior as when you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS).

■

[4] Using Fake REGISTER = Enables the Proxy Keep-Alive feature using SIP REGISTER messages. The device sends a REGISTER message every user-defined interval, configured by the 'Proxy Keep-Alive Time' parameter (in this table). The name in the Contact header of the REGISTER message is a fake name. Therefore, the REGISTER request is expected to fail and the device considers the proxy server as online if it receives a SIP 404 response. If the device receives a SIP response code that is configured in the 'Keep-Alive Failure Responses' parameter (in this table), the device considers the proxy as offline. You can also configure if the device uses its IP address, the proxy's IP address, or the device's name in the REGISTER message, using the [UseGatewayNameForOptions] parameter.

Note:

■

Proxy keep-alive using REGISTER messages (Using REGISTER) is applicable only to the Parking redundancy mode ('Redundancy Mode' parameter configured to Parking).

■

If you enable the Proxy Keep-Alive feature, the device can operate with multiple proxy servers (addresses) for redundancy and load balancing (see the 'Proxy Load Balancing Method' parameter).

■

For Survivability mode for User-type IP Groups, you must enable the Proxy Keep-Alive feature.

■

If you enable the Proxy Keep-Alive feature and the proxy uses the TCP/TLS transport type, you can enable the CRLF Keep-Alive feature, using the [UsePingPongKeepAlive] parameter.

■

If you enable proxy keep-alive using SIP OPTIONS messages (Using OPTIONS or Using OPTIONS on Active Server) or using fake REGISTER requests (Using Fake REGISTER), you can also enable the device to apply various settings (e.g., SIP message manipulation) of the IP Group that is associated with the Proxy Set, to these SIP messages. For more information, see the 'Proxy Keep-Alive using IP Group Settings' parameter in the IP Groups table.

■

If you enable proxy keep-alive using SIP OPTIONS messages (Using OPTIONS or Using OPTIONS on Active Server) or using fake REGISTER requests (Using Fake REGISTER), you can also configure how long the device waits before re-sending a keep-alive OPTIONS message once the device considers the proxy as offline (i.e., after all retransmissions, configured by the 'Failure Detection Retransmissions' have failed). This feature is configured by the [FailedOptionsRetryTime] parameter.

'Proxy Keep-Alive Time'

proxy-keep-alive-time

[ProxyKeepAliveTime]

Defines the interval (in seconds) between keep-alive messages sent by the device when the Proxy Keep-Alive feature is enabled (see the 'Proxy Keep-Alive' parameter in this table).

The valid range is 5 to 2,000,000. The default is 60.

Note: The parameter is applicable only if you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER.

'Keep-Alive Failure Responses'

keepalive-fail-resp

[KeepAliveFailureResp]

Defines SIP response codes that if any is received in response to a keep-alive message using SIP OPTIONS (Using OPTIONS or Using OPTIONS on Active Server) or using fake REGISTER requests (Using Fake REGISTER), the device considers the proxy as offline.

Up to three response codes can be configured, where each code is separated by a comma (e.g., 407,404). By default, no response code is defined. If no response code is configured, or if response codes received are not those configured, the proxy is considered online.

Note:

■

The SIP 200 response code is not supported for this feature.

■

The parameter is applicable only if you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER.

'Success Detection Retries'

success-detect-retries

[SuccessDetectionRetries]

Defines the minimum number of consecutive, successful keep-alive messages that the device sends to an offline proxy, before the device considers the proxy as online. The interval between the sending of each consecutive successful keep-alive is configured by the 'Success Detection Interval' parameter (see below). For an example of using this parameter, see the 'Success Detection Interval' parameter.

The valid range is 1 to 100. The default is 1.

Note: The parameter is applicable only if you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER.

'Success Detection Interval'

success-detect-int

[SuccessDetectionInterval]

Defines the interval (in seconds) between each successful keep-alive retries (as configured by the 'Success Detection Retries' parameter) that the device performs for offline proxies.

The valid range is 1 to 200. The default is 10.

For example, assume that the ‘Success Detection Retries’ parameter is configured to 3 and the ‘Success Detection Interval’ parameter to 5 (seconds). When connectivity is lost with the proxy, the device sends keep-alive messages to the proxy. If the device receives a successful response from the proxy, it sends another (1st) keep-alive after 5 seconds, and if successful, sends another (2nd) keep-alive after 5 seconds, and if successful, sends another (3rd) keep-alive after 5 seconds, and if successful, considers connectivity with the proxy as being restored.

Note: The parameter is applicable only if you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER.

'Failure Detection Retransmissions'

fail-detect-rtx

[FailureDetectionRetransmissions]

Defines the maximum number of UDP retransmissions that the device sends to an offline proxy before the device considers the proxy as offline.

The valid range is -1 to 255. The default is -1, which means that the setting of the global parameter [SIPMaxRtx] is applied.

Note:

■

The parameter is applicable only if you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS, Using OPTIONS on Active Server or Using Fake REGISTER.

■

If the device receives an ICMP error response (which indicates Host Unreachable or Network Unreachable) as opposed to a timeout, it may be desirable to abandon additional retries in favor of trying the next IP address (proxy) in the Proxy Set (typically required when Proxy Hot Swap is enabled). To enable this, configure the [AbortRetriesOnICMPError] parameter to 1.

Redundancy

'Redundancy Mode'

proxy-redundancy-mode

[ProxyRedundancyMode]

Enables proxy redundancy.

■

[-1] = (Default) Not configured. Proxy redundancy method is according to the settings of the global parameter [ProxyRedundancyMode].

■

[0] Parking = If the device operates with a proxy server that has the highest priority and the proxy goes offline, the device attempts to connect and operate with a different proxy that has the highest priority of all currently online proxies. However, once the device starts operating with this new proxy, it remains operating with it even if a previously offline proxy that has higher priority becomes online again.

■

[1] Homing = The device always attempts to operate with the proxy that has the highest priority of all currently online proxies. For example, if the device is currently operating with proxy server 200.10.1.1 that has priority 4, and then a previously offline proxy 200.10.1.2 that has priority 0 (i.e., a higher priority) becomes online again, the device attempts to connect and operate with proxy 200.10.1.2.

Note:

■

For proxy redundancy, you also need to enable the proxy keep-alive feature (see the 'Proxy Keep-Alive' parameter, above). The Homing redundancy mode is applicable only to proxy keep-alive using SIP OPTIONS (i.e., 'Proxy Keep-Alive' parameter configured to Using OPTIONS or Using OPTIONS on Active Server) or using fake REGISTER requests (i.e., 'Proxy Keep-Alive' parameter configured to Using Fake REGISTER). The Parking redundancy mode is applicable to all proxy keep-alive methods (SIP OPTIONS and SIP REGISTER).

■

From Version 7.20A.204, if you configure the parameter to Parking and the proxy keep-alive is done using REGISTER messages, when the proxy goes offline, the device arbitrarily chooses the next proxy to operate with.

■

To configure proxy priority, see the 'Proxy Priority' parameter in the Proxy Address table (below).

'Proxy Hot Swap Mode'

is-proxy-hot-swap

[IsProxyHotSwap]

Enables the Proxy Hot-Swap feature, whereby if the device sends a SIP message (INVITE or REGISTER) to the proxy and the message fails, the device re-sends the same message to a redundant proxy in the Proxy Set. The redundant proxy is determined by your Proxy Set configuration (i.e., redundancy mode and load balancing).

■

[0] Enable Only Before Alternative Routing = If the device sends a SIP message (INVITE or REGISTER) to the proxy and the proxy rejects it or there is no response from the proxy for a user-defined number of re-transmissions (configured by the [SIPMaxRtx] parameter), the device doesn't attempt to connect to any other proxy in the Proxy Set, and the SIP message fails.

However, if you've configured an SBC Alternative Routing Reasons Set for the IP Group (see Configuring SIP Response Codes for Alternative Routing Reasons), the device tries up to four online proxies in the Proxy Set. If it successfully connects to one of the redundant proxies, it re-sends the message to this proxy. This functionality doesn’t apply to REGISTER requests initiated by the device (e.g., for Accounts).

■

[1] Enable = If the device sends a SIP message (INVITE or REGISTER) to the proxy with which it is currently operating and any of the following occurs, the device re-sends the message to a redundant, online proxy:

✔

No response is received from the proxy each time the device re-sends it. The number of retransmissions is configured by the [HotSwapRtx] parameter. In this scenario, the device sends itself the SIP response code 408 (Request Timeout).

✔

The proxy rejects the message with a SIP response code that you have configured for the Alternative Reasons Set that is assigned to the IP Group ('SBC Alternative Routing Reasons Set' parameter) associated with the Proxy Set (see Configuring SIP Response Codes for Alternative Routing Reasons).

Note:You can employ alternative routing with this option. If no response is received from any of the redundant (online) proxies or the proxies reject the message with a SIP response code that you have configured for the Alternative Reasons Set that is assigned to the IP Group ('SBC Alternative Routing Reasons Set' parameter) associated with the Proxy Set, the device searches the IP-to-IP Routing table for an alternative routing rule and if found, sends the message to the rule's destination. For more information on the Proxy Hot Swap feature and alternative routing based on SIP response codes, see Configuring SIP Response Codes for Alternative Routing Reasons.

■

[2] Disable = (Default) Disables the Proxy Hot-Swap feature. If the device sends a SIP message (INVITE or REGISTER) to the proxy and the proxy rejects it or there is no response from the proxy for a user-defined number of re-transmissions (configured by the [SIPMaxRtx] parameter), the device doesn't attempt to connect to any other proxy in the Proxy Set, and the SIP message fails.

'Proxy Load Balancing Method'

proxy-load-balancing-method

[ProxyLoadBalancingMethod]

Enables load balancing between proxy servers in the Proxy Set.

■

[0] Disable = (Default) Disables proxy load balancing.

■

[1] Round Robin = The device sends outgoing SIP messages to the online proxy servers of the Proxy Set in a round-robin fashion. The order of the round-robin is determined by the listed order of the IP addresses in the Proxy Address table and their priority. You can configure the priority for each IP address using the 'Proxy Priority' parameter (see below).

For DNS-resolved IP addresses for proxy servers configured with an FQDN (including NAPTR and SRV, if configured), the priority is received from the DNS. The IP address list is refreshed every user-defined interval, configured by the [ProxyIPListRefreshTime] parameter. If a change in the order of the IP address entries in the list occurs, all load statistics are erased and balancing starts over again.

■

[2] Random Weights = The outgoing requests are not distributed equally among the proxy servers. The distribution is determined by the weight of the proxy servers. You can configure the weight per proxy server, using the 'Proxy Random Weight' parameter in the Proxy Address table (see below).

For proxy servers configured with an FQDN, the weight of each DNS-resolved IP address is received from the DNS server (using SRV records). However, if you have configured the weight for the FQDN in the 'Proxy Random Weight' parameter, this parameter's value overrides the weight from the DNS server. The device sends the requests in such a fashion that each proxy receives a percentage of the requests according to its' weight.

'Min. Active Servers for Load Balancing'

min-active-serv-lb

[MinActiveServersLB]

Defines the minimum number of proxies in the Proxy Set that must be online for the device to consider the Proxy Set as online, when proxy load balancing is used.

The valid value is 1 to 15. The default is 1.

Note: The parameter is applicable only if proxy load balancing is enabled (see the 'Proxy Load Balancing Method' parameter, above).

Advanced

'Classification Input'

classification-input

[ClassificationInput]

Defines how the device classifies incoming IP calls to the Proxy Set.

■

[0] IP Address only = (Default) Classifies calls to the Proxy Set according to IP address only.

■

[1] IP Address, Port & Transport Type = Classifies calls to the Proxy Set according to IP address, port, and transport type.

Note:

■

The parameter is applicable only if the IP Groups table's parameter 'Classify by Proxy Set' is configured to Enable (see Configuring IP Groups).

■

If multiple Proxy Sets are configured with the same IP address and associated with the same SIP Interface, the device may classify the SIP dialog (based on Proxy Set) to an incorrect IP Group. In such a scenario, the device uses the Proxy Set with the lowest Index number (e.g., Proxy Set ID #1 over Proxy Set ID #4). A syslog warning message is generated in such scenarios. Therefore, it is recommended to configure each Proxy Set with a unique IP address.

If multiple Proxy Sets are configured with the same IP address but associated with different SIP Interfaces, then classification based on Proxy Set can be correctly achieved.

If multiple Proxy Sets are configured with the same IP address and SIP Interface, but with different ports (e.g., 10.1.1.1:5060 and 10.1.1.1:5070) and the parameter is configured to IP Address, Port & Transport Type, classification to the correct IP Group is achieved. Therefore, when classification is by Proxy Set, pay attention to the configured IP addresses and this parameter. When multiple Proxy Sets are configured with the same IP address, the device selects the matching Proxy Set in the following order:

✔

Selects the Proxy Set whose IP address, port, and transport type match the source of the incoming SIP request (regardless of the settings of this parameter).

✔

If no match is found for above, it selects the Proxy Set whose IP address and transport type match the source of the incoming SIP request (if the parameter is configured to IP Address Only).

✔

If no match is found for above, it selects the Proxy Set whose IP address match the source of the incoming SIP request (if the parameter is configured to IP Address Only).

For example:

Index	Classification Input	Proxy Address (IP:Port;Transport Type)
1	IP Address, Port & Transport Type	10.10.10.10:5060;UDP
2	IP Address only	10.10.10.10:5060;UDP
3	IP Address only	10.10.10.10:5070;UDP
4	IP Address only	10.10.10.10:5060;TCP

✔

Incoming SIP request from 10.10.10.10:5060;UDP: Best match is #1 and #2 (same priority); second best match is #3 (due to transport type); third best match is #4.

✔

Incoming SIP request from 10.10.10.10:5080;TLS: Best match is #2, #3 and #4 (same priority).

✔

Incoming SIP request from 10.10.10.10:5070;TCP: Best match is #4 (due to transport type); second best match is #2 and #3 (same priority).

'DNS Resolve Method'

dns-resolve-method

[DNSResolveMethod]

Defines the DNS query record type for resolving the proxy server's hostname / domain name (FQDN) into an IP address(es).

■

[-1] = Not configured. DNS resolution method is according to the settings of the global parameter [ProxyDNSQueryType].

■

[0] A-Record = (Default) The device performs a DNS A-record query to resolve the FQDN into an IP address(es).

■

[1] SRV = If the proxy address is configured with a domain name without a port (e.g., domain.com), the device performs an SRV query. The SRV query returns the host names (and their weights). The device then performs DNS A-record queries per host name (according to the received weights). If the configured proxy address contains an FQDN with a port (e.g., domain.com:5080), the device performs a regular DNS A-record query.

■

[2] NAPTR = The device performs a NAPTR query. If successful, the device sends an SRV query according to the information received in the NAPTR response (in preference order). The SRV response is resolved to obtain one or more FQDNs, which are then resolved with A-record queries. If no online servers are found, the resolution process returns to the next SRV record in the NAPTR response, and so on. If the NAPTR query fails, the device performs a SRV query according to the configured transport type. If the configured proxy address contains an domain name with a port (e.g., domain.com:5080), the device performs a regular DNS A-record query. If the transport type is configured for the proxy address, a NAPTR query is not performed.

■

[3] Microsoft Skype for Business = The device performs an SRV query as required by Microsoft when the device is deployed in a Microsoft Skype for Business environment. The device sends a special SRV query to the DNS server according to the transport protocol configured in the 'Transport Type' parameter (described later in this section):

✔

TLS

✔

TCP: "_sipinternal._tcp.<domain>" and "_sip_tcp.<domain>".

✔

Undefined: "_sipinternaltls_tcp.<domain>", "_sipinternal_tcp.<domain>", "_sip_tls.<domain>" and "_sip_tcp.<domain>".

The SRV query returns the host names (and their weights). The device then performs DNS A-record queries per host name (according to the received weights) to resolve into IP addresses.

Note: The device caches the DNS-resolved IP addresses of the last successful DNS query of a Proxy Set. The device uses the cache if the DNS server goes offline. This functionality occurs regardless of the setting of the [DNSCache] parameter.

'Accept DHCP Proxy List'

accept-dhcp-proxy-list

[AcceptDHCPProxyList]

Enables the device to obtain the Proxy Set's address(es) from a DHCP server. When enabled, it sends a DHCP request with Option 120 (SIP server address) to a DHCP server. This occurs upon a DHCP refresh (lease renewal). When the device receives the list of IP addresses (or DNS) from the server, it adds them to the Proxy Set (replaces any existing IP addresses or DNS).

■

[0] Disable (default)

■

[1] Enable

Note: When enabled, the device uses UDP and port 5060.

'TLS Remote Subject Name'

tls-remote-subject-name

[TLSRemoteSubjectName]

Defines the Subject Name of the TLS certificate received from the remote side when establishing a TLS connection with the Proxy Set.

When the device receives a certificate from the remote side, it validates the certificate by comparing the certificate's Subject Alternative Names (SAN) with the Proxy Set's addresses (IP address and FQDN) and the parameter's value. If a SAN matches an address or the parameter's value, the device considers the certificate as valid and establishes the TLS connection and allows the call.

If there is no match and the SAN is marked as "critical", the device doesn’t establish a TLS connection and rejects the call. If there is no match and the SAN isn't marked as "critical", the device compares the Proxy Set's addresses (IP address and FQDN) and the parameter's value with the certificate's Common Name (CN). If any of them match, the device establishes a TLS connection and allows the call; otherwise, it doesn't establish a TLS connection and rejects the call.

The valid value is a string of up to 100 characters. By default, no value is defined.

Note:

■

The parameter is applicable only if you configure the Proxy Set's parameter 'Peer Host Name Verification Mode' (or global parameter [PeerHostNameVerificationMode]) to Server Only or Server & Client.

■

If you configure the parameter, it overrides the global parameter [TLSRemoteSubjectName].

■

For incoming messages, the 'TLS Mutual Authentication' parameter (global or per SIP Interface) must be enabled.

■

For outgoing messages, either the 'TLS Mutual Authentication' parameter (global or per SIP Interface) or the 'TLS Client Verify Server Certificate' parameter must be enabled.

■

A certificate may include multiple SAN types (e.g., Email, DNS, URI, and IP). The only SAN types that the device compares for matching are DNS and IP.

'Peer Host Name Verification Mode'

peer-host-name-verification-mode

[PeerHostNameVerificationMode]

Enables the device to verify the Subject Name of the TLS certificate received from the remote side for authentication and establishing a TLS connection.

■

[-1] Use Global Settings = (Default) The settings of the global parameter [PeerHostNameVerificationMode] is applied.

■

[0] Disable = No certificate verification is done.

■

[1] Server Only = The device verifies the certificate's Subject Name only when it acts as a client for the TLS connection.

■

[2] Server & Client = The device verifies the certificate's Subject Name when it acts as a server or client for the TLS connection.

If the device receives a certificate from a SIP entity (IP Group) and the parameter is configured to Server Only or Server & Client (or global parameter is used and configured to one of these options), it attempts to authenticate the certificate based on the certificate's address:

If the connection was classified to a Proxy Set, the device compares the certificate's Subject Alternative Names (SANs) with the Proxy Set's addresses (IP address or FQDN) and the 'TLS Remote Subject Name' parameter's value. The device checks the FQDN itself and not the DNS-resolved IP addresses.

If a SAN matches an address or the 'TLS Remote Subject Name' parameter's value, the device considers the certificate as valid and establishes the TLS connection and allows the call.

If there is no match and the SAN is marked as "critical", the device doesn't establish a TLS connection and rejects the call. If there is no match and the SAN isn't marked as "critical", the device compares the Proxy Set's addresses (IP address or FQDN) and the 'TLS Remote Subject Name' parameter's value with the certificate's Common Name (CN). If any of them match, the device establishes a TLS connection and allows the call; otherwise, the device doesn't establish a TLS connection and rejects the call.

Note:

■

If you configure the parameter to Server & Client, configure the [SIPSRequireClientCertificate] parameter to Enable.

■

If you configure the parameter to Server Only, configure the 'TLS Client Verify Server Certificate' [VerifyServerCertificate] global parameter to Enable.

■

For FQDN, the certificate may use wildcards (*) to replace parts of the domain name.

'TCP/TLS Connection Reuse'

connection-reuse

[ConnectionReuse]

Enables the reuse of the initially established TCP or TLS connection between the device and the proxy server for all subsequent SIP requests sent to the proxy server. New out-of-dialog requests (e.g., INVITE or REGISTER) use the same secured connection. One of the benefits of enabling the parameter is that it may improve performance by eliminating the need for additional TCP/TLS handshakes with the proxy, allowing sessions to be established rapidly.

■

[0] Disable = The device establishes a new TCP or TLS connection with the proxy for each SIP request.

■

[1] Enable = The device uses the same TCP or TLS connection for all SIP requests with the proxy.

■

[2] Use Global Settings = (Default) This feature is according to the global parameter [EnableTCPConnectionReuse].

Note: For SIP responses, the device always uses the TCP/TLS connection of the corresponding incoming SIP request, regardless of the parameter's setting.

'In-Call Route Mode'

in-call-route-mode

[InCallRouteMode]

Enables the device to send in-call SIP messages (e.g., re-INVITE and BYE) to the currently active proxy if the proxy to which the dialog-initiating INVITE message was sent is currently offline. This is applicable when the Proxy Set has multiple proxies (IP addresses). This feature occurs even if the currently active proxy was offline when the call was established.

■

[0] Disable = (Default) The device sends in-call SIP messages to the currently active proxy if it was online upon call establishment. If it was offline upon call establishment, the device sends the in-dialog message to a different proxy in the Proxy Set. If no additional proxies exist, the device doesn't send the message.

■

[1] Enable = The device sends in-call SIP messages to the currently active proxy, regardless of its state (i.e., online or offline) when the call was established.

Note:

■

When enabling this feature, it's recommended to configure the Proxy Set's 'Proxy Keep-Alive' parameter to Enable.

■

When enabling this feature, make sure to configure all proxies in the Proxy Set with the same transport type (e.g., all TCP). Otherwise, unexpected behavior (even call failure) may occur.

■

The device's generated CDR displays only the proxy used for the dialog-initiating INVITE message.

Proxy Address Table

'Index'

proxy-ip-index

[ProxyIp_ProxyIpIndex]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Proxy Address'

proxy-address

[ProxyIp_IpAddress]

Defines the address of the proxy server (Proxy Set). The address can be defined as an IP address in dotted-decimal notation (e.g., 201.10.8.1) or FQDN. You can also specify the port using the following format:

■

IPv4 address: <IP address>:<port> (e.g., 201.10.8.1:5060)

■

IPv6 address: <[IPV6 address]>:<port> (e.g., [2000::1:200:200:86:14]:5060)

Note:

■

When configured with an FQDN:

✔

You can configure the periodic interval at which the device performs DNS queries to resolve the FQDN into IP addresses. For more information, see the [ProxyIPListRefreshTime] parameter.

✔

The device caches the DNS-resolved IP addresses of the last successful DNS query of a Proxy Set, which is used if the DNS server goes offline. This functionality occurs regardless of the setting of the [DNSCache] parameter.

✔

You can configure the method (e.g., A-record) for resolving the domain name into an IP address, using the 'DNS Resolve Method' parameter in this table (see above).

■

You can configure the device to use the port indicated in the Request-URI of the incoming message, instead of the port configured for the parameter. To enable this, use the 'Route Using Request URI Port' parameter for the IP Group that is associated with the Proxy Set (Configuring IP Groups).

■

If you are configuring the Proxy Sets with IP addresses, it is highly recommended to configure each Proxy Set with a unique IP address. Configuring multiple Proxy Sets with the same IP address can cause problems classifying incoming SIP requests to source IP Groups based on Proxy Set. If you have configured multiple Proxy Sets with the same IP address, the device uses the Proxy Set with lowest Index number. For example, if you have configured Proxy Set ID #1 and Proxy Set ID #4 with the same IP address, the device uses Proxy Set ID #1 to classify the incoming SIP request to an IP Group.

However, configuring multiple Proxy Sets with the same IP address, but with different SIP Interfaces is acceptable for classifying incoming SIP requests to source IP Groups based on Proxy Set.

For more information on determining the Proxy Set, see the 'Classification Input' parameter (above) parameter .

■

If you want to implement SCTP with multi-homing for the Proxy Set, you must configure all the addresses of the Proxy Set with the same remote SCTP port number. In addition, you must configure the 'Transport Type' parameter to SCTP for all the addresses (see below). For more information on SCTP with multi-homing, see Configuring SCTP Multi-homing

'Transport Type'

transport-type

[ProxyIp_TransportType]

Defines the transport type for communicating with the proxy.

■

[-1] = (Default) Not configured. The transport type is according to the settings of the global parameter [SIPTransportType].

■

[0] UDP

■

[1] TCP

■

[2] TLS

■

[3] SCTP

Note: When you configure the transport protocol as SCTP, the device assumes that all the addresses of the Proxy Set are a group of multi-homing remote addresses for a single proxy. Therefore, if you configure the parameter to SCTP for this address, you must also configure the parameter to SCTP for all the other addresses of the Proxy Set. In addition, you must configure all the addresses of the Proxy Set with the same remote SCTP port number (in the 'Proxy Address' parameter above) . For more information on SCTP with multi-homing, see Configuring SCTP Multi-homing

'Proxy Priority'

priority

[ProxyIp_Priority]

Defines the priority of the proxy. When a proxy server goes offline, the device attempts to connect to an online proxy server that has the highest priority.

The valid value is 0 to 65535, where 0 is the highest priority and 65535 the lowest. The default is 0.

Note:

■

You must configure both priority and weight (or none of them). In other words, if you configure this parameter, you must also configure the 'Proxy Random Weight' parameter. If you don't configure this parameter, you must also not configure the 'Proxy Random Weight' parameter.

■

If weight and priority are not configured for any of the proxy servers of the Proxy Set, the order in which the addresses (IP addresses and FQDNs) are listed in the table determine their priority (i.e., top-listed address has the highest priority).

■

For FQDNs, weight and priority of DNS-resolved IP addresses are determined by the DNS server. However, this parameter's value overrides the priority received from the DNS.

■

If you have configured at least one of the proxy servers of the Proxy Set with weight and priority, the device prioritizes all the configured proxy servers according to weight and priority. In this case, proxy servers that are not configured with priority (i.e., 0) are considered as proxy servers with the highest priority.

■

The parameter is applicable to load balancing (see the 'Proxy Load Balancing Method' parameter), and homing and parking redundancy (see the 'Redundancy Mode' parameter).

'Proxy Random Weight'

weight

[ProxyIp_Weight]

Defines the weight of the proxy.

The valid value is 0 to 65535, where 0 is the highest weight and 65535 the lowest. The default is 0.

Note:

■

The parameter is applicable only if you configure the 'Proxy Load Balancing Method' parameter to Random Weights. For more information on weights, see this parameter.

■

You must configure both priority and weight (or none of them). In other words, if you configure this parameter, you must also configure the 'Proxy Priority' parameter. If you don't configure this parameter, you must also not configure the 'Proxy Priority' parameter.

■

For proxy servers configured with FQDNs, this parameter's value overrides the weight received for DNS-resolved IP addresses from the DNS server.